<html>
<head><meta charset="utf-8"><title>emplacement · t-compiler · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/index.html">t-compiler</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html">emplacement</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="133749841"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133749841" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133749841">(Sep 11 2018 at 18:10)</a>:</h4>
<p>I’ve been thinking about emplacement lately and how we could "fix" the optimisation-related issue that led to us removing the feature altogether. I’ve come to a conclusion that it is necessary for the whole call graph starting at a function, which is RHS of the emplacement operator, to return its result via an <code>sret</code> for emplacement to work. This can be done either by:</p>
<p>1. Implicitly creating copies of functions that use the desired calling convention;<br>
2. Requiring users to explicitly annotate functions that are able to participate in emplacement;<br>
3. Changing the "Rust" ABI to always be emplacement-capable.</p>
<p>All of the solutions have their problems, namely: (1) results in a binary bloat; (2) is just inconvenient to use; (3) has a cost when emplacement is not used.</p>



<a name="133749884"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133749884" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133749884">(Sep 11 2018 at 18:11)</a>:</h4>
<p>Oh, and in addition to all that, it is also fairly critical that we do not copy all over our stack in debug mode somehow (which requires some sort of a MIR-level propagation to finally happen)</p>



<a name="133749936"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133749936" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133749936">(Sep 11 2018 at 18:12)</a>:</h4>
<p>Although this specific lack of optimisation is slightly orthogonal IME.</p>



<a name="133750097"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750097" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750097">(Sep 11 2018 at 18:15)</a>:</h4>
<p>I'm not sure I understand what trade-off you're getting at. What's the cost with (3), are you talking about small return values that are more profitable to return in registers?</p>



<a name="133750447"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750447" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750447">(Sep 11 2018 at 18:21)</a>:</h4>
<p>Sure. That’s specifically a tradeoff for the "solution number 3"</p>



<a name="133750472"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750472" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750472">(Sep 11 2018 at 18:21)</a>:</h4>
<p>oh, another problem with number 3 is that it won’t work if there's a non extern-Rust function call anywhere in the callgraph</p>



<a name="133750553"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750553" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750553">(Sep 11 2018 at 18:23)</a>:</h4>
<p>I don't understand why we'd force an out-pointer based ABI on functions returning register-sized data. If the data is this small, storing it to the destination it <em>in the caller</em>, if necessary, is basically just as good as storing it there in the callee to begin with</p>



<a name="133750581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750581">(Sep 11 2018 at 18:23)</a>:</h4>
<p>the problem we want to avoid is repeatedly memcpy'ing aggregates of significant size, not moving any data at all twice</p>



<a name="133750682"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750682" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750682">(Sep 11 2018 at 18:25)</a>:</h4>
<p>This is the orthogonal problem to the emplacement feature itself that I’ve mentioned above.</p>



<a name="133750836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750836">(Sep 11 2018 at 18:27)</a>:</h4>
<p>Also, in my personal opinion being able to avoid moving any data at all twice is a very, very useful property</p>



<a name="133750897"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133750897" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nagisa <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133750897">(Sep 11 2018 at 18:28)</a>:</h4>
<p>Its just that achieving this in C++ is super involved, and I’d like to have something better for Rust.</p>



<a name="133751056"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/emplacement/near/133751056" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Hanna Kruppe <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/emplacement.html#133751056">(Sep 11 2018 at 18:31)</a>:</h4>
<p>I am not even talking about avoiding memcpy's in code like <code>let x = foo(); let y = x;</code>. I'm saying, for something like <code>place &lt;- (foo(), bar());</code> we'd generally want <code>foo</code> and <code>bar</code> to write their return values directly to space allocated for the tuple, without any large memcpy's, <em>but</em> no change in ABI is needed if they return something small like <code>i32</code> because <code>call foo; mov DWORD PTR [tuple.0], eax</code> is basically as good as <code>lea rdi, [tuple.0]; call foo</code></p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>